Date: Sat, 23 Apr 94 04:30:19 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #126 

To: Ham-Digital 


Ham-Digital Digest Sat, 23 Apr 94 Volume 94 : Issue 126 


Today's Topics: 
A86cpu RFI Problems 
ftp mail server source for ax.25 for LINUX operating system? 
Need Poor Man's Packet Article! 
On-Air Encryption?.. (2 msgs) 
Ottawa PI and PI2 driver for Linux 
Running Pactor and GTOR on the Same BBS Port 
TAPR Radio 
TI 320C26 DSP Eval Kit 
Unsubscribe 
WEFAX 
Who is ordering GPS receivers from Motorola? 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 19 Apr 94 00:26:29 -0400 

From: ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu! 
panix!ddsw1!news.kei.com!ub!newserve! sarah! psinntp!psinntp!wlnntp.psi.com! 
usenet@network.ucsd.edu 

Subject: 486cpu RFI Problems 

To: ham-digital@ucsd.edu 


>DATE: Sun, 17 Apr 1994 13:37:50 GMT 

>FROM: J.D. Cronin <jdc3538@ultb.isc.rit.edu> 

> 

>In article <2975456864.6.p00123@psilink.com> p00123@psilink.com writes: 
>>Probably the biggest factor is to have a computer that is FCC type B 


>>approved for RFI. Type B is the more stringent standard. 

>> 

>>Type A is not approved for use in the home or for sale for home use. 
>> 

>>-Seth 

> 

>A FCC type approval sticker is meaningless. I purchased a mailorder 
>486 DX2/66 PC, which emitted gobs of RFI from its unshielded 

>plastic case, keyboard and monitor. I complained to the local FCC 
>field office, who directed me to the FCC BBS. (Don't have the 
>number handy, call your local field office.) 

> 

>The registration number was 2 or 3 years old, for a 25 mhz 386 
>machine. It didn't specify the type of cabinet, keyboard or monitor. 
> 

>Your options are: 

>- Purchase reputable brand names. Look for a decent quality cabinet. 
>The plastic front piece should have a metal coating on the inside. 
>Also look for spring contacts to ground that metal coating to the rest 
>of the case. 

> 

>- Complain to the FCC. They probably can't help, but remaining silent 
>means you accept the situation as it is. 

> 

>- Fix the PC yourself. You have to do this anyway if you're into 
>digital modes that require the PC and radio to be in close proximity. 
> 

>73...Jim 

>N2VNO 


I bought a mail-order 486DX2/50, but I checked first when I ordered it 
about not only the Type-B rating, but the metal case. From what I could 
determine over the phone, it sounded good. It was good. I have the PC 
literally right next to the radios (HF and VHF) and have no problems, 
even on the digital modes. I did not have to do anything to chase RFI. 
I do have things grounded. 


I don't know why anyone would keep a machine that is such a problem, 
unless you have the time and inclination to go through all that... If 
it's too noisy, send it back. After all, it's a big investment and 
you're gonna have to live with it. 


-Seth 


Date: 20 Apr 94 16:12:47 
From: idacrd.ccr-p.ida.org!idacrd!n4hy@uunet.uu.net 


Subject: ftp mail server source for ax.25 for LINUX operating system? 
To: ham-digital@ucsd.edu 


The GW4PTS AX.25 Package is available via anonymous ftp on sunacm.swan.ac.uk 
in the /pub/Linux/Radio directory. 


Bob 

Robert W. McGwier 

Center for Communications Research 
Princeton, N.J. 08520 

(609) -279-6240(v) (609) -924-3061(£) 


| n4hy@ccr-p.ida.org Interests: ham radio, 
| scouts, astronomy, golf (o yea, & math!) 
| ASM Troop 5700, ACM Pack 53 Hightstown 

| I used to be a Buffalo . . . NE III-120 


Date: 22 Apr 94 01:54:15 GMT 

From: wri!pea@uunet.uu.net 

Subject: Need Poor Man's Packet Article! 
To: ham-digital@ucsd.edu 


Does anyone have a copy of the August 1991 73 Magazine 
Poor Man's Packet article that ran on pages 8-14?? If 
you do, would you please consider faxing me a copy?? 


I have the pmp11 program that I've been tinkering with, 
but evidently there is some info in this article I need 
to get the program up and running. And, unfortunately, 
none of my local libraries have the back issue any longer. 


My fax number is: 217-359-1761 
Thank you for your help! 


Bruce 


Date: Wed, 20 Apr 1994 18:32:59 GMT 

From: ihnp4.ucsd.edu! galaxy.ucr.edu!library.ucla.edu!csulb.edu!csus.edu! 
netcom.com!dfajardo@network.ucsd.edu 

Subject: On-Air Encryption?.. 

To: ham-digital@ucsd.edu 


Richard Whittaker (rwhittak@docwhitehoorse.doc.ca) wrote: 
: Greetings from Whitehorse!.. 


: I've been working with the DOC on a project to use digital radio in disaster 
: Situations to connect with the Internet via RF links... 


<text deleted> 

:.... although they raised 

: the question of security of the data stream between the remote site (the 

: on-scene packet station), and the dish. This link would be made on 
pre-determined "commercial" frequencies, so the question arose as to what 

: encryption schemes there were to bolster security of information passing 

: over the air... Does any such scheme currently exist, and if so, where would 

: one find it and how good is it?.. Any information would be of great 

: assistance... 

There is a serious question of what is being protected, and what level 

of protection is desired. If you simply dont want the media or the casual 

public listening in on city operations, you could use something like 

PGP to encrypt each message (I don't know where it is currently archived, 

but you could find it easily with GOPHER). A LOT o£ people on the internet 

use it. This would require the originator of the mesage encoding the 

message before sending it. 


If your reasons for needing security go beyond this level, then I suspect 
the answer is no, and it probably can't be done in a secure fashion 
without getting some kind of crypto gear. (Beware of the DES trap; DES 
can't be implemented in software and still be in compliance with the 
spec - software implementationsof DES are dis-allowed!). 


Because Amateur radio is not allowed to use encryption, no development 
of hardware for this purpose has been done to the best of my knowledge. 


Good Luck! 

Doug Fajardo Sysop, LABBS (CA0Q199@CAWG.PAR) 
dfajardo@netcom.com Asst. CAWG Packet Cord. (South) 

Eagle 249 (CAP) Squadron 35 Com Officer (Pacoima, CA) 
WB6KNY (HAM) chief Cook and bottle washer, too! 
CAO249@CA0199.PACR.CAWG (Packet) Phone(Voice): (818) 985-841 

Doug Fajardo Sysop, LABBS (CA0Q199@CAWG.PAR) 
dfajardo@netcom.com Asst. CAWG Packet Cord. (South) 

Eagle 249 (CAP) Squadron 35 Com Officer (Pacoima, CA) 
WB6KNY (HAM) chief Cook and bottle washer, too! 
CAO249@CA0199.PACR. CAWG (Packet) Phone(Voice): (818) 985-841 


Date: Tue, 19 Apr 1994 09:26:59 -0400 

From: ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!pitstop.mcd.mot.com! 
mcdphx!schbbs!mothost! lmpsbbs!NewsWatcher!user@network.ucsd.edu 

Subject: On-Air Encryption?.. 


To: ham-digital@ucsd.edu 


In article <1994Apr16.173958.2447@clark.dgim.doc.ca>, 
rwhittak@docwhitehoorse.doc.ca (Richard Whittaker) wrote: 


Greetings from Whitehorse!.. 


satellite dishes scattered around the territory. We've demonstrated the 
effectiveness of this system to "the powers that be", although they raised 
the question of security of the data stream between the remote site (the 
on-scene packet station), and the dish. This link would be made on 
pre-determined "commercial" frequencies, so the question arose as to what 
encryption schemes there were to bolster security of information passing 


one find it and how good is it?.. Any information would be of great 
assistance... 


Thanks in advance... 


Cheers, 
Rich W. 
Richard Whittaker: Snailmail: 1102 Pine St, Whitehorse YT Y1A 4E8 
Internet E-Mail: rwhittak@orion.docwhitehorse.doc.ca 
Geographic Coords: 60 Deg., 45', 53" N., 135 Deg., 7', 17" W. 
Amateur Radio: VY1RW, VY1IRW@VY1DX, VYIRW@VY1BBS, 145.010 MHz 


VV VV VV VV VV VV VV VV VV VV VV MV 


Once we get beyond the old adage "Never answer a question with another 
question," the first question I ask is the working definition of "security" 


in line 5 of your query. Are you/they trying only to guarantee message 
integrity (that what is received is what was sent), are they concerned with 
authentication (that the entire message was not sent by or received by 
other than the named parties), are they worried about some casual listener 
eavesdropping and disclosure to the public, or are they planning to occupy 
Internet/UseNet with militarily classified or secret messaging? The answer 
to this question will at least define the starting point and weed out 
methods 

which may be inadequate for the task at hand. 


The integrity issue is easily handled by using robust error-checking data 
protocols over the RF channels. This is quite common over commercial HF, 
but don't expect any great throughput on HF, especially with band 
conditions 

like they were for the last week! The authentication issue probably should 
involve a PGP system. Casual eavesdropping is as much a problem on Internet 


I've been working with the DOC on a project to use digital radio in disaster 
situations to connect with the Internet via RF links to router stations with 


over the air... Does any such scheme currently exist, and if so, where would 


as it is on HF radio, since anyone can watch all the packets go by if they 
choose. The military security issue and serious encryption of the message 
contents can easily be handled using products and techniques currently 
available to those agencies through their normal procurement channels, 
albeit at rather high price tags for the mission you have described. 


FLAME ON! - The public and private sources who fund the various national 
relief organizations and their regular operations charter them to deliver 
assistance to affected areas in times of need. Relief agencies who are more 


worried about the encryption of their operational data than getting 
emergency 

relief into the field during natural disasters are not providing the 
services 

to those who need them, but to themselves instead by diverting funds from 
the intended use. 


Karl Beckman, P.E. < STUPIDITY is an elemental force for which > 
Motorola Comm - Fixed Data < no earthquake is a match. -- Karl Kraus > 


The statements and opinions expressed here are not those of Motorola Inc. 
Motorola paid a marketing firm a huge sum of money to get their opinions; 
they have made it clear that they do not wish to share those of employees. 


Amateur radio WA8NVW @ K8MR.NEOH.USA.NA NavyMARS VBH @ NOGBN.NOASI 


Date: Wed, 20 Apr 1994 18:51:55 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!cs.utexas.edu!utnut!nott!cunews! 
news@network.ucsd.edu 

Subject: Ottawa PI and PI2 driver for Linux 

To: ham-digital@ucsd.edu 


Announcing the Ottawa PI and PI2 card driver for Linux 

This driver was designed for use with the AX.25 kernel support from 

Alan Cox (version ALPHA 017). It works with kernels supporting NET3 
(1.1.5 and higher). This is the first generally available ALPHA release, 


and there are some restrictions, explained in the README. 


If you are unfamiliar with the Ottawa PI2 synchronous interface card 
for amateur radio, send mail with any subject/body to: 


pi-info@hydra.carleton.ca 


The latest driver versions (currently at 0.5 ALPHA) are available 
for anonymous ftp from from hydra.carleton.ca, in 


/pub/hamradio/packet/tcpip/linux 


Dave 

va3dp 

Dave Perry | Any opinions stated here are mine 
dp@hydra.carleton.ca | and have nothing to do with Carleton University 


va3dp@ve3jf£.#eon.on.noam | 


Date: 22 Apr 94 02:25:49 GMT 

From: dog.ee.lbl.gov!agate!howland.reston.ans.net!usenet.ins.cwru.edu! 
cleveland.Freenet.Edu!ag807@ucbvax.berkeley.edu 

Subject: Running Pactor and GTOR on the Same BBS Port 

To: ham-digital@ucsd.edu 


SB HF @ WW < NO8M $62887_NO8M 
Both Pactor/GTOR On BBS Port (1/2) 
R:940420/1604z 62887@NO8M.7#NEOH.OH.USA.NA 


RUNNING KAM PACTOR AND GTOR ON THE SAME BBS PORT 


Real time observations have shown that GTOR is twice as fast as 
Pactor on a 80 meter path. Although we have not been able to check 
the performance from different locations (but will from many 
locations soon), it is apparent that GTOR will be superior to 
Pactor. 


The availability and popularity of Kantronics TNCs is quite limited 
outside of the United States. BBS support of both Pactor and GTOR 
would be an advantage. In fact, until some further support of GTOR 
is made by equipment suppliers shipping outside of the United 
States, Pactor has to be supported. (1) (2) 


(NOTE 1: Not all people have Internet or a good VHF support 
network. I have many DX stations who use the BBS who do not 
have access to the Internet. Contrary to what some people 
(those who are opposed to HF forwarding) would like you to 
believe, transferring information to South America via VHF 
nodes is not quite possible yet.) 


(NOTE 2: It appears that a number of BBS software packages 
will offer support for GTOR. None have been released yet 
although one is obviously in beta.) 


Two KAMS were run in parallel by running the radio port lines in 
parallel. Running these to a Kenwood TS-450 showed that dual 
porting will not work in the FSK mode. The KAM uses a simple 
transistor switch to hold the FSK line low unless a toggle is 
required. Rather than reverse engineer that, a change to AFSK was 
made. (3) 


(NOTE 3: Two virtually identical HF MSYS BBS systems were 

tested over a long period of time from many locations under 
many conditions. One system was operated with FSK and the 

other with AFSK. If there was a difference between FSK and 
AFSK, it was so slight that it was not measurable. AFSK is 
fine.) 


Once the radio was run to the two KAMs, an immediate problem 
surfaced. Pactor operation on 3632.1 Mhz. (which is 3630 mark to 
a FSK radio) worked fine. A switch to Pactor showed the radios 
were not tuned to the same frequency. 


/EX 

SB HF @ WW < NO8M $62888_NO8M 

Both Pactor/GTOR On BBS Port (2/2) 
R:940420/1604z 62888@NO8M.7#NEOH.OH.USA.NA 


After a bit of experimentation and calculation, we came up with the 
following two setup files for the TNCs. 


For the GTOR KAM: For the Pactor KAM: 
<control-c>x <control-c>x 
<control-c>d <control-c>d 
<control-c>d <control-c>d 
pbbs 0 pbbs 0 

intf£ term intf£ term 
xflow off xflow off 
flow off flow off 
crsup off crsup off 
prekey 0 prekey 0 
pthuff on pthuff on 
pmode gtor pmode pactor 
delete 0 delete 0 


echo off echo off 


gterrs 80 space 2295 


space 2295 mark 2095 
mark 2095 shift modem 
shift modem pactor 

gtor 


Now either KAM can seize the radio and respond. 
THE IDEAL NEXT STEP: 


It seems like all the pieces are in the KAM to allow it to 
recognize a connect from any HF mode. Whether it has the 
horsepower to do that kind of operation may be the problem. Using 
the GSCAN function, an external program could be written to monitor 
the port, determine what flavor of connect is coming in, and set 
the TNC to that flavor. It could then assemble packets and feed a 
BBS program some sort of Host or KISS mode information. 


With XT systems going for $100, it may be possible to dedicate such 
a box to doing this function. Use the XT to do the external 
codework that the KAM, now used only as a modem, is feeding it. 

The XT would then feed the BBS the resultant frames. 


Finding someone dedicated to writing such a function is the only 
remaining obstacle. 


73, 
Steve 
NO8M@NO8M.#4NEOH.OH.USA.NA 
ag807@cleveland.freenet.edu 
/EX 
73, 
Steve 


ag807@cleveland.freenet.edu 
NO8M@NO8M.#4#NEOH.OH.USA.NA 


Date: Wed, 20 Apr 1994 22:22:18 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech! howland.reston.ans.net!europa.eng.gtefsd.com! 
news.umbc.edu! eff! news. kei.com!ub! penny! jane! hansen@network.ucsd.edu 

Subject: TAPR Radio 

To: ham-digital@ucsd.edu 


Bruce Langos (blangos@wtcp.DaytonOH.NCR.COM) wrote: 


: In 1989 the TAPR folks showed a prototype of a 25 watt Radio with 

: integrated packet(TNC). This was shown at the Dayton Hamfest. Was it 
: every brought to market? I have been out of packet for many years 

: and want to get active again. 


No, the project was dropped. 


Date: 21 Apr 94 16:29:43 GMT 

From: dog.ee.lbl.gov!agate!iat.holonet.net!vectorbd! jpll@ucbvax.berkeley.edu 
Subject: TI 320C26 DSP Eval Kit 

To: ham-digital@ucsd.edu 


Felton Mitchell (fmitch@netcom.com) wrote: 
: Jim Lill (jpll@vectorbd.com) wrote: 
: Has anybody done anything with TI's $99 320C26 Evaluation Kit? 


: who has the kits? anybody have an 800 number where they can be obtained??? 


most electronic distributors: Arrow, Marshall, etc. 


-Jim Lill- Vector Board BBS 
jpll@vectorbd.com 716-544-1863/2645 
wa2zkd@wb2psi.d#wny.ny.usa.na GEnie: ZKD 


Date: 22 Apr 94 13:15:10 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Unsubscribe 

To: ham-digital@ucsd.edu 


Unsubscribe 


Date: Thu, 21 Apr 1994 15:30:46 GMT 

From: swrinde!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio- 
state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!alberta!quartz.ucs.ualberta.ca! 
tribune.usask.ca! kakwa.ucs.@ihnp4.ucsd.edu 

Subject: WEFAX 

To: ham-digital@ucsd.edu 


dts@world.std.com (Daniel T Senie) writes: 
> I have heard of people using their HF receivers, to receive the 


> WEFAX signal from Spacenet3 T17. Is anyone out their doing this, or 
> could tell me how it is done? 


The way this is done is by feeding the baseband video output from 

the satellite receiver into the HF receiver. Note that the HF revr 

must be set for FM mode. By tuning across the video signal in the HF 
range you will find all kinds of specialty narrowband signals, including 
RTTY and WEFAX. I'm not sure of the exact frequency on Spacenet3 but 
perhaps someone else out there does. Try all the transponders, though. 
You'd be amazed at what you might come up with. 


John Boudreau 
ve8ev@inukshuk.gov.nt.ca 


Date: 21 Apr 1994 08:05:13 -0500 

From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!not-for-mail@network.ucsd.edu 
Subject: Who is ordering GPS receivers from Motorola? 

To: ham-digital@ucsd.edu 


Greetings all: 


A fellow Amateur Radio colleague ( W8RIK ) asked me to post this request for 
him . 


He heard over the Internet that another ham is making a large 
purchase of GPS receivers ( for GPS/APRRS experiments) from 
Motorola. Does anyone know this Hams name or how to contact him? 


He would like to combine the orders for possible savings. 
If you have information please contact: 


Podniesinski@SC3101.Med.Buffalo.Edu 


Thanks! 
N2IJRQ 


Date: Wed, 20 Apr 1994 21:30:31 GMT 

From: ihnp4.ucsd.edu! library.ucla.edu!csulb.edu!csus.edu!netcom.com! 
parker@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <ColwOu.2KJ@alsys.com>, <parkerCo0J5z5.67A@netcom.com>, 
<pineappCoKCL1.L6F@netcom.com>° 
Subject : Re: Internet > Packet gateways?? 


I don't have any idea why it is freezing up. I tried it, and it did the same 
for me. The only other thing that I can think of is going through the front 
door and giving the command to go into conference mode. I don't know how to 
do that on that particular system though. If it's that important try leaving 
a message to the operator to see what's wrong with it. 


End of Ham-Digital Digest V94 #126 
KAKKKKKKKKKKKKKAKKKKKKEKKER RK 


